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Lots of items to cover this quarter - the last 3 months have 

been an exceptionally busy and productive quarter for TPRS. 

: We'll run down the list here briefly, and look forward to more 

APRS Networking on fe eaitel y 

TexNet, Part 2 

Native APRS support in TexNet - Bob Morgan has gotten 

running and operational a version of the TexNet code that 

APRS via TexNet permits network-wide APRS use. We think it's the first native 
network-support for APRS anywhere. Bob has a separate 

Announcement article on APRS in this newsletter. 


: Internet Network Extension Running - Support for Internet 
TPRS Node Assignments.. as a means to tunnel between TexNet ae is up and 
operational at a couple of sites. Our first node in Louisiana is 
planned to come on line using the Internet to provide the 
connectivity. Jim, WU8V is supplying the equipment at the 
ae LA end, and Bob has a node operational in Austin for 
Note: due to space limitations, Bob connection of these nodes into the TexNet backbone. All of 
Morgan’s AX-IP article will appear the work thus far has been on a Linux platform, which 
next time. provides the encapsulation of AX.25 frames into Internet IP 
frames. There's actually an Internet standard RFC for map- 
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(Continued from page 1) 
ping AX.25 to IP, and it is available in some 
version of UNIX derivatives. 


TPRS Fall Digital Symposium - the TPRS fall 
digital symposium looks to be very interesting this 
year. With the rise of usage of Linux in the ham 
community, we are going to devote some tutorial 
time on the topic of Linux and ham radio. An 
expert in Linux, Stu Green will present the funda- 
mentals of Linux, and much of the more advanced 
topics. In addition, lots of other interesting sub- 
jects. We'll talk about how we should inter- 
network TexNet and the Internet, as well as setting 
up APRS forwarding. See the article in this QR 
describing the time and date, and the agenda for 
this year's meeting, which will be held Saturday, 
December 12th in Austin, Texas. 


TAPR FHSS Radio - During the last 3 months, the 
2nd turn of the digital board was made, and this 
got the Ethernet interface working. In addition, the 
port of XINU and the TCP/IP stack is now up and 
running on the radio. It's fun to be able to ping 
such a little board and know that it contains a 
complete stack on it. A UDP driver for helping us 
debug the boards is also working on the unit - 
that's the beauty of a complete kernel - it is just a 
few lines of code once all the software routines are 
in place. The total stack right now takes about 
110 kilobytes - we have 2 megabytes of FLASH 
memory on the board, so room for lots more 
goodies. Also, we have the hardware that pro- 
vides convolutional coding and decoding now 
working. It's operational at 300,000 symbols/sec- 
ond, and will easily do much faster than that. Less 
than 5 years ago, the horsepower to do this type of 
coding at this rate was simply not available com- 
mercially, now it fits on one chip. We are continu- 
ing work on the RF board, and some progress has 
been made. More to come in the next QR. 


Bluetooth Consortium - A good presentation on 
the Bluetooth consortium was made at the IEEE 
Mobicom '98 conference this year (held in Dallas 
for the 1st time) by IBM; Mobicom is a conference 
on mobility in communications. Bluetooth is a 


consortium of 200+ companies. The founding 
(Continued on page 3) 
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companies were Nokia, Ericsson, Intel, Toshiba, 
and IBM. The purpose of the consortium is to 
define standards for wireless interconnection of 
communicating devices. The purpose is to provide 
a standard for about a 10-meter range frequency- 
hopped spread-spectrum radio in the 2.4 GHz. 
band, at about 10 milliwatts output. An option to 
go up to about 100 meters is provided. The radio 
provides about 700 kilobits/second transfer rate, 
and is designed to provide ad-hoc automatic net- 
working. This means that merely being within 
range of such devices provides automatic estab- 
lishment of network connections. The concept is 
that no one device can contain all the functions that 
people need, such as cell phone, pager, wireless 
LAN, wireless PDC, electronic caledar, etc. The 
Bluetooth standard allows each of the devices to 
network into your local home or business in such a 
way as to automatically extend the functions of 
each of these devices into a network with minimal 
power dissipation and minimal cost. It may lead to 
the development of standard highly-integrated chip- 
sets for devices that are very low in cost. It will be 
interesting to see where the consortium eventually 
leads. 


September DCC Wrap-up - The 1998 ARRL/ 
TAPR digital communications conference held in 
Chicago in September is now history. It seems that 
the quality of the technical papers and the presen- 
tations was really superb this year. APRS contin- 
ues to be a hot topic, and Bob Bruniga demon- 
strated a Kenwood handheld with built-in 1200 and 
9600 modems. With a 3-element yagi out in the 
parking lot, he was copying data from one of the 
low-orbit amateur satellites onto his laptop 
(everything hand-held!). Other papers were very 
good, and the new head of the FCC office of 
Engineering and Technology (OET) Dale Hatfield 
attended the entire event (as did Dave Sumner, the 
VP of ARRL). | think they all came away quite 
impressed with the high technical quality and 
unique relevance of new developing technology in 
amateur radio. Tim Shepard presented a paper on 
networking with millions of packet stations, based 
on his Ph.D. dissertation at MIT - very interesting. 
Tim was interviewed in EE Times magazine shortly 
after this presentation about his new start-up com- 
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pany. 


PRUG Sessions at 1998 DCC conference - Sev- 
eral particularly interesting sessions were pre- 
sented by the Packet Radio User’s Group of Japan 
(PRUG). PRUG has developed a prototype direct- 
sequence radio operating in the 2.4 GHz band 
(there are slight differences in frequencies between 
the US and Japan in this band). This prototype 
appears to be very well designed from an experi- 
mentation point of view. 


All of the radio protocol, and well as future planned 
software-executed forward-error-correction (FEC) 
is performed on a workstation. This workstation is 
in-turn attached via 10-base-T Ethernet cable to a 
Z80 module (and Ethernet NIC card) located next 
to the radio. The advantage is that the long run of 
cable up the tower is 10-base-T cable, and the 2.4 
GHz coax cable is kept to about 12 inches in 
length. This Z80 processor performs very limited 
functionality, it removes a temporary header used 
to send packets from the workstation to the Z80 
(based on UDP/IP) and transmits the remainder of 
the frame on the radio. It performs the comple- 
mentary function in the received direction. 


The key advantage of this unusual encapsulation 
method is that all of the software that defines the 
network, the media access (MAC) protocols, the 
FEC codes, etc. resides within a single UDP pro- 
cess on the workstation (which can as easily be a 
PC). This means that experimentation with differ- 
ent MAC protocols, new routing protocols, etc. is 
easily accomplished and simple to develop. PRUG 
is cooperating with the Tokyo Institute of Technol- 
ogy to experiment with, and develop new protocols 
for packet radio using this technology. It’s well 
suited for a university program because the re- 
searcher can spend most of the time focusing on 
the network aspects, and much less so on real-time 
issues, software integration issues, etc. This 
makes it possible for a master’s student to com- 
plete a project in one or two semesters with the 
PRUG hardware. We will look forward to reading 
the papers published by these researchers on their 
spread-spectrum, network, MAC, and routing ex- 
periments at future DCC’s, hopefully! It’s a great 
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example of how amateur radio can provide a 
foundation for and contribute to important techni- 
cal work. 


The current raw data rate is about 800 kilobits per 
second, and the spreading code is an 11-bit 
Barker sequence. All radios on the channel uti- 
lize the same spreading sequence, so collisions 
and multicasting are possible. Thus, the radio 
appears much like one channel in today’s packet 
network except that the data rate is much higher. 
The channel access protocols are similar. PRUG 
presented a paper on the use of improved channel 
access protocols. They analyzed the theoretical 
throughput of a channel under CSMA/CD (current 
packet protocol) and MACA protocols (MACA 
was described by Phil Karn, KA9Q in a 1991 DCC 
paper). 

-30- 


——————————————————————————————— 
Announcement 


TPRS Fall Digital Symposium 


The TPRS fall digital symposium will be held on 
December 12th this year. There is a lot of change 
in networking, our network, the Internet, and some 
interesting new applications such as APRS. The 
theme of this conference is inter-networking, and 
there will be lots of interesting material on Linux, 
APRS, TexNet-over-IP, and new modes. It should 
prove to be a good session. We will also be 
developing guidelines about how to approach an 
ISP, and arrange Internet connections to various 
amateur applications. Hope to see you there. 


Texas Packet Radio Society 
Fall Digital Symposium 
Saturday, December 12th, Austin, Texas 
UT Austin. 
Sanchez Education Building, room # is TBD. 
Signs with the room number will be posted. 


Friday night, Dec 11th 
Sholz Garden, Austin 


7:00 PM+ Dinner at 
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Texas Packet Radio Society, Inc. 


TPRS was founded in 1985 and is an educational, public service, and scientific 
research non-profit corporation. Texas Packet Radio Society goals are: 


1- design and research amateur radio packet networks 
2- provide education in the area of general packet usage 


To accomplish better communications in the region, TPRS has been 
organizing statewide working groups to cover various networking topics. The 
current working groups are the Mailbox/BBS Group, TCP/IP Group, and the 
TexNet Support Group. TPRS hopes that these working groups will help 
promote information exchange in their respected areas in Texas. New working 
groups are formed as needed to provide channels for discussion and to help 
provide direction for that area of digital communications. Anyone can participate 
in a working group; TPRS membership is not required. 


TexNet 

TPRS has established a digital packet network protocol, a standard 
hardware package for the network nodes, and software modules that implement 
the TexNet network. 

The basic design philosophy of TexNet is an open, inexpensive, multi- 
resource, high speed ‘backbone’ with access through multi-connect capable local 
nodes. On the high speed side, TexNet is a 9600 baud network system. For local 
access, compatibility with the typical 2 meter AX.25, 1200 baud, AFSK/FM. 
station is the operational norm. Other baud rates and modulation techniques can 
be supported on the primary user port or secondary port. The system is totally 
compatible with both versions of the AX.25 protocol specifications for user 
connections. With these general specifications, TexNet has been designed and 
tested to enable all users to take advantage of this high speed, full protocol 
protected packet network system. 

Each node offers, in addition to TexNet access, local area digipeater service, 
2 conference bridges for full protocol protected roundtable or net operation, a full 
mult-connect, multi-user mailbox system, a local console for installation and 
maintenance setups, a debugger module for long distance and local software 
monitoring,and an interface for a weather information server for regional weather 
information, if available. 

The NCP-PC (TexNet for PC) creates a direct interface to the PC platform. 
The Z80 based PC card supports 4 channels for communications. This co- 
processor approach allows the AX.25 and TexNet-IP to run on the card without 
affecting the PC. This allows the full power of the PC to be used for network 
applications. The versatility of this board is only now being developed and 
applications are endless. 


The TexNet Network 
The Texas TexNet network system has been operational since October 
1986. When fully operational, the network reaches from the border of Mexico to 
Missouri. Use of the Texas TexNet system is open to all amateur operators. 
TPRS has been coordinating the installation of the Texas TexNet system. Further 
expansion of the system depends entirely upon the amateur community. 


INFORMATION 
TPRS is interested in spreading our information and research efforts as 
widely as possible. We want other groups involved with packet efforts to get in 
contact with us. We will provide information for those amateur packet groups 
that are interested in this system for their areas. If you would like more 
information concerning TPRS or TexNet, please drop a letter to: 


Texas Packet Radio Society, Inc. 
P. O. Box 50238 
Denton, Texas 76206-0238 


TPRS MEMBERSHIP 
TPRS membership is widespread with most members located in Texas, but 
members are located in other states and in foreign countries. Membership is 
open to any interested person. If you are interested in becoming a member and 
receiving the TPRS Quaterly, please send your name, address and call with 
membership dues of $12 per year. A membership application is available 
elsewhere in this issue. 
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Saturday, December 12th UT Austin, Room # TBD 
Session I. Tutorials 8:30 - 9:30 AM 
A. Linux systems -Stu Green 
* Setting up Linux as a gateway router. 
* How to setup routing tables, default routes, etc. 
- Static vs. dynamic addresses, class-c ad- 
dresses, etc. 
* Tunnels - what they do, how to set one up. 
* Proxies / IP address masquerading 
* Slip and PPP on serial interfaces 
* Ethernet interfaces 


Session II. Project Reports 9:45 - 12:00 
A. FlashCard OS Project - John Koster, W9DDD 
B. FHSS radio project status - Tom McDermott, 
N5EG 

C. TexNet - APRS capability, AX.25 tunneling - 
Bob Morgan, WB5AOH 

D. ISP interconnection project - Joe Borovetz, 


12:00 - 1:30 
Session III. Operational Issues 1:30 - 3:00 
A. BBS, DXC - David Wolf, WO5H 
B. APRS - Mike Heskett, WB5QLD 


Session IV. White Paper brainstorm session 

3:15 - 5:00 
Greg Jones, WDS5IVD - discussion leader 
Purpose is to define a white paper that can be used 
as a guide to advise people how to safely setup a 
gateway including routing, maintenance, and ad- 
ministration for IP interconnection arrangements. 
The interconnection arrangements that this paper 
should cover include: 


- AX25IP tunneling 
- Spread spectrum radio interconnection to an 
ISP 
- Straight and Masqueraded addressing 
- Dynamic and Static addressing 
- VPN (Virtual Private Networking) for closed tun- 
nel groups 
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APRS Networking on TexNet, Part 2 
Bob Morgan, WB5AOH 


If some method pops up, | will investigate whether 
it is feasible, but for the forseeable future, it will be 
subject to the usual behaviors of manually man- 
aged routing. That means it may be subject to the 
disappearing act, and also typos, omissions, un- 
forseen needs, and the like. Probably the most 
acceptable semiautomated solution for the future 
would be an automated network manager that 
would have a master scheme stored in it, and the 
automation would continually re-examine the net- 
work nodes tables to spot deviations and omis- 
sions, and correct them to match the stored plan. 
But that's for later on. In the meantime, the manual 
destinations are editable by a remote sysop, so 
they can be changed to allow for new destinations, 
temporary operations and circumstances like wide 
area searches or long race coverage events. 


Another feature. It is much simpler to allow APRS 
packets to enter on any port of an APRS capable 
node, than to determine if a particular port of a 
node should be listening for APRS packets. In an 
emergency, we would want to accept them uncon- 
ditionally. In fact, the emergency most easily 
forseen would be to mount a tracker on an airplane, 
connect it to a UHF radio on the TRUNK frequency, 
and it would be heard at EVERY TexNet node in the 
state, and we could achieve the widest possible 
coverage with the least hardware. From an air- 
craft, that might mean continuous coverage from 
Sherman to Brownsville. 


Now for the bad news. We normally will have to 
add APRS capability to a TexNet node here and 
there by adding a TPRS 1200b modem to the spare 
NCP port, and of course come up with another VHF 
radio, feedline, antenna and the accessories. Well, 
we don't have the modem kits, for one thing. | will 
probably breadboard one or two for the first few 
vital sites, but in the long run, we will need to 
reissue and maybe redesign the modem kits. Also, 
some nodes like Austin, Corpus, and Ndallas don't 
have a spare port. They are already used by a 
wireline port, so those nodes are just out of luck as 
far as local APRS is concerned. They will still need 

(Continued on page 6) 
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to have the eprom updated for multitudes of rea- 
sons, so that the enroute congestion filters will be 
in place, and so that the emergency all-port input 
mechanism will function. We do have one node 
just sitting and waiting for a 2M radio on its main 
channel (SDALLAS), and if other considerations 
that relate to the long term continued availability of 
that site are met, we could drop just a radio and 


interested. At this point, as they say, it's only 
software. ONLY. 


| ought to take time to point out an underlying 
philosophy about TexNet's use of the internet. 
TexNet will use the internet facilities, which are 
obviously outside the realm of amateur radio, to 
further extend RADIO packet connectivity. In other 
words, TexNet will continue to provide a packet 
RADIO channel to a RADIO AMATEUR user so 


. that they can use TexNet to get to another AMA- 


Hopefully it will come to pass, possibly by press 
time. No promises here, and of course local 
donations for a radio for that area (Dallas) will be 
cheerfully accepted. Version 1.75 itself, when it is 
completely written and debugged, needs to be 
retrofitted widely across the network as soon as 
practical, as it provides many fixes and features in 
addition to just APRS. 


Does any of this stuff relate to the Internet? Yes, 
eventually. Eventually TexNet will come to depend 
on internet wormholes for some of its trunking. 
That project is also under construction, as they say. 
But having TexNet nodes hooked up to the internet 
provides APRS with a very exciting prospect. 
There are now a few internet APRS bridges, which 
are an attempt at tying APRS together nationwide. 
This is done by using some code included with 
user's APRS programs running on PC's that are 
dialed up on the internet, to send and receive any 
APRS packets received locally, so that they can be 
bridged nationwide, and displayed on any APRS 
PC system that is also dialed onto the internet. 
What will be investigated later in the future is the 
possibility that the TexNet-Internet interface nodes 
might also be programmed to ship TexNet net- 
worked APRS packets to these internet APRS 
bridges, so that any TexNet APRS packets would 
automatically appear on these resources. For one 
thing, it would be pretty handy for multiple local 
EOC's watching APRS/CAP search activities to all 
sign onto the internet locally, connect to the APRS 
bridges, and all simultaneously see the search area 
over the whole state, even if they weren't in radio 
range of TexNet. Another possibility is putting 
TexNet networking info, like the node stats, avail- 
ability, current users, and the like, real-time onto 
the TPRS web pages for use by whoever was 
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TEUR RADIO station at some other place. In other 
words, radio in, radio out. It isn't a substitute for a 
phone line or any other non-radio system. It is for 
hams to use to extend their range on the RADIO. 
From some of the comments that | see go by from 
time to time, | think that point may not be fully 
recognized. We wouldn't be in the habit of keeping 
TexNet running if it wasn't there to make packet 
RADIO work on the RADIO for the USERS. 


So how do | use TexNet to get my APRS packets 
from one node to another? 


1. Specify a DIGIPEAT address of WIDE or some- 
thing equally acceptable, at a point in the address 
list of the packets you are sending that will be 
heard by the nearest TexNet node. Note locally to 
see that is really being retransmitted by the TexNet 
node. TexNet UI digipeating does implement two 
new digipeating schemes: WIDE-N SSID decre- 
menting of WIDE-N SSID's 1-7 where the SSID is 
decremented each repeat, and callsign substitution 
of the node callsign for WIDE and RELAY. So, 
APRS packets locally digipeated can be positively 
traced to see if the TexNet node did indeed digipeat 
them. No digipeat, no network forwarding either. 
Make sure the local digipeat is happening before 
going further. (There MAY be a few nodes that 
may be set up to force these packets onto the 
APRS port if received on some other port of that 
particular node, so watch the APRS port for out- 
put). Of course, you have to make your packets 
actually arrive intact and copyable at the node, so 
you could have to do things to make the TNC, 
Radio, antenna, or propagation succeed. And, of 
course, the originating and destination TexNet 
nodes have to have the APRS ports installed and 

(Continued on page 7) 
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running the new firmware. The new firmware also 
identifies itself as an APRS node, and should place 
itself on the maps. 


A note regarding digipeat addressing. TexNet 
always has restricted the digipeat address list of 
any packet to a maximum of four addresses, and 
for some connections to TexNet itself, to less. We 
did this to save on RAM memory use in the node, 
so we could handle more packets. It is a mathe- 
matical fact that the more repeats are used in a 
path, the less likely the packet is to reach a final 
destination, so we don't support unproductive 
packet activity. So, for TexNet to even copy the 
packet, there must be four or less digipeat slots 
specified by the originator. More than that, TexNet 
just ignores the packet during receive. Now, it 
might be necessary to use some intermediate sta- 
tion to relay your packets to even get TO the 
TexNet node, and that is just fine. Do whatever you 
have to do to make the packet reach the node 
through other stations if necessary, just don't use 
more than four address slots to do that. It is 
common APRS practice to set digipeat aliases of 
digipeaters to either "WIDE" or "RELAY" for unifor- 
mity, so that mobiles can move about the country 
and not have to continually reprogram their ad- 
dressing, and this certainly applies here. Note that 
as you test it for digipeating locally, there is also 
some programming in the digipeat program that 
disallows duplicates of recent packets, so transmit 
slightly different contents on repeated tests. More 
on that later. 


2. The "TO" address should be matched to the 
destination list of the local TexNet node. If it isn't 
matched, something has to change. If it isn't con- 
figured properly in your own setup, add it. It should 
already be properly set if the APRS is properly 
installed, and | wouldn't expect that to be a com- 
mon problem. If APRS firmware IS installed on 
your local node, and that will happen slowly as 
hardware and volunteer labor and equipment per- 
mits, then look at the slots 81-90 of the nodes table 
to see what matches. If no match, let the network 
sysop know what you think is needed, and to 
where, so that the manual configuration process 
will take place. Also note that the address match- 
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ing for this one function does employ the wildcard 
match, in this case the question mark. For in- 
stance, APR???? matches any of the following 
destinations: APRS, APRSW, APRSM, APR807, 
etc, and for all possible 16 SSID's. In fact, this will 
be the normally expected entry in most of the 
nodes. 


3. Then, use it. Keep in mind that some reverse 


routing may not exist, and might not even be 
feasible in some circumstances. So you might not 
be able to take full advantage of the bidirectional 
messaging that is built into APRS. The primary 
intention is to make trackers and object positioning 
widely available over the network. 


Now for the promised real story of the CAP aircraft 
tracker. 


The spring and early summer drought that spread 
over much of Texas and the southwest brought fire 
dangers to some scary levels throughout the re- 
gion. Some parts of central Texas, mostly the hill 
country, are not equipped with organized fire spot- 
ting resources, as are other regions more moun- 
tainous that may have fire watch towers in forests. 
But we still had a real tinderbox on our hands. The 
forestry departments and the Civil Air Patrol joined 
forces to provide a daily fire watch aerial search 
once or twice an afternoon over the hill country. 
This operation began in June, 1998 and will proba- 
bly last until the drought breaks or the fire danger 
subsides, which may be October. They thought 
they might need some additional communications 
capability, and they contacted the amateur commu- 
nity (ARES) in Austin, where the EOC was being 
used to manage the effort. The flights were origi- 
nating in Austin, and flying a search pattern to the 
south and west, over Boerne and Kerrville to 
maybe as far as Uvalde, and then back to the north 
and east over Llano and Burnet, and returning to 
Austin. We ran a test, with a portable battery 
powered tracker provided by Ron Parsons, 
W5RKN. This consisted of a GPS receiver, an HT 
and a TNC, and a gelcell 12V battery, inside a 
common enclosure which was placed in the rear 
seat of the plane, and the transmit antenna was 
inside the cabin also. We chose to use a 2 meter 

(Continued on page 8) 
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voice repeater near Henly (southwest of Austin) 
and recover the packets from the repeater output. 
We installed a laptop at the EOC in downtown 
Austin, connected its video output to a video pro- 
jector so it could be seen by anyone in the room, 
brought up WinAPRS, and displayed maps show- 
ing the aircraft location. The tracker also had 
battery voltage telemetry so we could stimate bat- 
tery capacity consumption. We had more or less 
continuous coverage from takeoff until around Ker- 
rville, where the portion of the flight southwest of 
there was lost. We reacquired it around Fredricks- 
burg, and followed it over Llano and Burnet back in 
to Austin where it landed. This was done on a test 
basis for two days in a row, which happened to 
occur on Field Day weekend. | had my laptop also 
running WinAPRS, copying the aircraft, at the 
Austin field day site, and demonstrated it as it 
happened to those interested in watching it. Both 
days as the aircraft approached Austin, | was able 
to note the aircraft on the map as it flew overhead 
and establish 

visual contact with the aircraft as it went over. One 
incident occured on the second day, where we 
observed the aircraft make several circles around 
Burnet. The pilot reported to the EOC that he was 
trying to locate the Llano airport. They informed 
him of his location over Burnet instead, some 25 or 
so miles east of where he thought he was. Anyhow 
he managed to find Austin shortly thereafter. We 
aren't sure if that is why we didn't have the tracker 
on the plane afterwards. APRS continued to be 
employed at the EOC as a standalone mapping 
and projection tool throughout the rest of the sea- 
son. 


From this test, some of the programming require- 
ments for TexNet support of APRS started to 
emerge. | had been trying unsuccessfully to estab- 
lish the requirements for the year or two previous to 


that little exercise in reality. | determined that we 
had to have some system of _ sysop- 
reprogrammable destinations for APRS packets so 
that we could control from one incident to the next 
where the packets needed to be sent. It had to use 
existing TexNet code and tables in so far as practi- 
cal, and had to use an existing sysop editing 
function that we use to edit routing, so the routing 
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table was internally partitioned. It was obvious that 
we had to provide for emergency packet input on all 
ports including the trunk, since the network 
wouldn't suddenly acquire new radios and modems 
on APRS channels overnight. At the time, the fire 
danger was really quite high, and | was in a hurry to 
provide something, in case it might help put out 
fires. Anyone that followed the unprecedented 
evacuations of whole counties in Floida should 
appreciate the fact it could have occured in Texas 
also. So far we are lucky and have emerged 
relatively unscathed, although | think that the fire 
count over the state numbered in the thousands. 


| need to mention a little about the WIDE-N scheme 
of digipeater addressing, and also callsign substitu- 
tion by digipeaters. These ideas came into being in 
the APRS environment, as digipeating is the first 
means used to extend APRS coverage. If a sender 
wanted to send his packets in all directions through 
expanding circles of coverage of digipeaters, he 
might use a path of "APRS V WIDE,WIDE,WIDE". 
We assume that there existed a regular network of 
digipeaters all with an alias of "WIDE" and each 
repeat would expand coverage outwards. But it 
also creates loops and redundant transmissions 
that choke the frequency each time it is stimulated 
by a new packet. Someone came up with the idea 
of WIDE-N, where the digipeater was programmed 
to DECREMENT the SSID each time it was re- 
peated, instead of setting the repeat-bit (the bit that 
shows up as an asterisk next to the digipeat ad- 
dress on a monitor frame, showing it had been 
"used"). So, now if one desires to expand his 
transmission through three concentric rings of digi- 
peaters, he would set his path to "APRS V WIDE- 
2". The first digi would adjust the SSID to -1, the 
next repeat would adjust it to -0, and the last one 
would rewrite it completely to its own callsign and 
then set the "used" bit. At this point it is possible to 
detemine a little bit more about where it had been 
repeated. Along with this came a scheme that Bob 
Bruninga suggested to cut down on duplicate pack- 
ets, the idea of storing some checksum/count data 
on the last several currently digipeated packets, 
and checking received packets against this list to 
see if they appear to be duplicates. If they are 
dupes, why clutter things up by sending them 

(Continued on page 9) 
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again. So, we now compute and store the call- 
sign+datafield checksum and bytecount, along with 
a timer value, for several recent UI packets, and if 
it matches previous packets we simply don't repeat 
them. That also applies to packets accepted to 
send over the network. No digipeat, no network 
destination either. It only applies to UI's since that 
behavior would destroy any retry attempts on digi- 
peated connections. There has to be a timer that 
will let them expire after a few minutes, so that 
legitimate static information can be refreshed at the 
10 to 20 minute intervals. This logic is now built 
into all TexNet version 1.75 digipeating, along with 
more ROM table space to store more digipeat 
aliases. You can test this behavior by manually 
initiating polls at quick intervals from an APRS 
keyboard, and observing that only the first one gets 
repeated, until the timer finally makes the duplica- 
tion obsolete after a few minutes, where it will again 
respond on only the first packet. The originator's 
own "FROM" callsign is included in the checksum 
calculation so that more than one station can 
originate a poll or other identical datafields and not 
have their packets filtered out as "duplicates". This 
is NOT the same count/checksum as is used to 
error-check the packet itself during receive. In fact 
the FCS itself isn't even input to the NCP processor 
from the SIO IC. The digipeat program recom- 
putes it, and only parts of it as necessary, just the 
"from" and the datafield, since parts of the address, 
like SSID and repeat-bit would be different for 
various duplicated packets and we wanted to 
recognise them as duplicates since they were origi- 
nally the same transmission, just repeated here 
and there. 


Another ongoing APRS project of mine, related to 
TexNet and TPRS, is to produce a worthwhile 
APRS tracker EPROM that TPRS could dis- 
tribute. This has been an on-and-off project of mine 
for a couple of years, and it is still intermittently 
progressing. It is in reality a version of TexNet, but 


without the networking. It is intended to be in- 
stalled in a TNC2/compatible clone, like a MFJ1270 
or a PacComm Micropower-2, along with a GPS 
receiver, and function as a standalone tracker, with 
some improvements on the current crop of stuff. It 
already is parsing the GPS output completely, and 
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reformatting it into an APRS protocol packet. It 
doesn't transmit position unless the GPS is locked 
onto a valid fix, so we don't transmit fictitous or 
stale data. It determines if it is moving or parked 
and adjusts the transmit update rate accordingly 
from one to ten minutes. It incorporates data from 
several of the NMEA sentences into just the one 
APRS sentence, so we include position, course/ 
speed, time, altitude, icon symol into just one 
packet. It sets up a time-slotting method of anticol- 
lision stretegy based on callsign. In other words, 
callsigns of different suffix first character are as- 
signed different second slots within the GPS 
minute, so they are less likely to transmit at once 
and collide. For the aircraft tracker example, | use 
an external input, which could be a pushbutton, to 
generate serial-numbered "objects" and transmit 
the object and its position. This is useful for 
implementing a "virtual deployable marker". Sort of 
like dropping traffic cones or aerial chalk markers 
along a route, but without physically throwing any- 
thing over the side. They just show up on every- 
ones APRS maps. They would be useful for 
marking observations of fires or storms or crash 
sites, and reporting them to observers. There is 
also periodic telemetry available, both from internal 
GPS engine temperature, and from optional A/D 
converters installed within the TNC, which might 
track battery voltage, weather parameters, com- 
pass headings, or whatever. There is still some 
work to be done on this project, such as user 
programmability. Presently parameters are just 
burned into the EPROM. A viable product would be 
user programmable and store parameters in 
BBRAM. It would also be remotely programmable 
so that parameters could be changed while it was 
in motion doing its job. So far, it is only tested 
against the Garmin-20 engine, and needs to be 
verified and tweaked against other common GPS 
models. Also, Differential or DGPS input needs to 
be added. So stay tuned. When it is available, 
TPRS may be offering them for sale. 


For more detailed information about APRS itself, 
see the TAPR web site, or the websites of the 
APRS developers themselves. TAPR is a good 
starting point for the other sites. There is a very 


active mail reflector for APRS on the TAPR SIG. If 
(Continued on page 10) 
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you sign onto it, expect a lot of e-mail, useful and 
otherwise. 


APRS adds one more function to packet radio 
which TexNet supports. Currently, TexNet mainly 
exists to forward BBS mail and DXC spots, al- 
though keyboard users of packet certainly are en- 
couraged. Support your own local node operators. 
It seems like lately that user ports have been falling 
into increasing disrepair and we have seen network 
traffic drop accordingly. Stuff doesn't last forever. 
Although it doesn't demand constant attention it 
needs occasional repairs. In the future APRS is 
expected to become another supporting and sup- 
ported function of our network, but it won't happen 
by itself. It needs local support. We still hope to 
see the network change and expand. 


APRS networking via TexNet announcment 
Bob Morgan, WB5AOH 


Earlier this summer | completed a modification to 
the TexNet networking code which allows TexNet to 


| planned to have this done a year 
earlier, but things didn't work out due to some other 
bugs in the code being modified, unrelated to the 
APRS modifications. Bob Bruninga probably won- 
ders what became of it during this time, but finally 
it is done. We don't like to announce vaporware, we 
want to wait until it works. | announced it locally at 
Austin SummerFest (regional hamfest), and had 
planned to find a little bit of informal soapbox time 
at DCC, but the trip fell through and | didn't make it. 
Anyhow, here it is. The nationwide internet APRS 
bridges notwithstanding, | believe that this repre- 
sents the first amateur packet layer 3 radio network 
to support APRS as such. This was quite a 
departure, since layer 3 networking normally im- 
plies connected user traffic, and APRS doesn't fall 
into that category with its UI frame traffic. 


Presently, where the latest beta versions of TexNet 
v 1.75 are installed, which is at Waco, San Antonio 
(Alamo node), and a couple of test frames around 
Austin, TexNet will both digipeat APRS locally, and 
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transport APRS to those other nodes where it will 
be retransmitted remotely. We hope to expand 
APRS networking to several other nodes in Texas 
in the following months, assuming the local users 
of APRS are interested in helping outwith some 
equipment donations, mostly radios for 144.39. 
Last night an APRS station in San Antonio became 
operational and it proved that the temporary setup 
there was working as intended, so it is high time to 
announce it, although | still consider the software to 
be in the betatest status. It is getting about time to 
pack it up and release it for the rest of the network, 
whether or not APRS is in use at any particular 
node or not. It is a general software upgrade. 


Here is how it works to the user: The key to 
pushing APRS through TexNet is to ensure that you 
can digipeat through the local node. Any UI packet 
that is addressed via any of the digipeat addresses 
of upgraded TexNet nodes is also eligible to be 
transported elsewhere, if its "TO" address matches 
any entry in the node's destination table. The 
destination table is something that is manually 
maintained by a network sysop. Itis a partition of 
the regular node routing table, and associates an 
address, with appropriate wildcards, with node- 
numbers of destination nodes where it will be sent 
if it matches. A typical entry in most nodes is the 7 
character group: APR???? which matches any 
SSID of any address beginning with APR, such as 
APRSW, APRSM, APR807, etc. Up to five entries 
of destination nodenumbers can be associated with 
that address, and more entries can be used if 
needed since the whole 10-line table is exhaustively 
searched. Different uses, such as SKYWRN, can 
be sent to different destinations, and the sysop can 
edit the tables as needed to support special events 
and emergencies. The sysop editing function is a 
remote manual process. If something is haywire or 
needs to be changed or added, contact a sysop. 
Currently that is either me WB5AOH, in Austin, or 
Harry, NOCCW in San Antonio. 


Currently, there is a separate port on 144.39 in 
Waco at a fairly decent location, although not 
exceptional it does cover most of town for mobiles. 
There are some low-range test situations in NW 
Austin, probably too limited to access most of the 

(Continued on page 11) 
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time. Recently, the temporary setup in San Anto- 
nio became operational on 145.09 which is the 
regular user port of ALAMO node in NE SAT. We 
plan to installa proper 144.39 radio on some other 
site downtown when time and resources permit. 
The Waco site does hear APRS packets from 
D/FW when the band opens up, and | have seen a 
few packets from places in and around Houston 
and east Texas a few times. 


What happens then? The node will digipeat the 
packet locally, and will find a match in the destina- 
tion table if there is one. For each match it finds, it 
ships a copy of the packet as a network datagram 
to each destination. It replaces the digipeat fields 
in a scheme that will show the entry node callsign 
as the first digipeater, regardless of what they may 
have been to begin with. When it arrives at some 
destination node, the second digipeater field will be 
filled in with the destination node's callsign, and no 
others. First, that enables the receipient to get 
some idea of where it came from, although any 
digi's prior to entering the network won't be known 
at that point. Second, since there are no unre- 
peated digipeat addresses, there won't be any 
possibility of an endless loop, since it is anticipated 
that most or all of the nodes will be on 144.39 and 
will be hearing each other when the band is open. 


First, there is redundant- 


What else happens? 
packet filtering in place on the receiving nodes. 
Every UI packet that is being digipeated and possi- 
bly transported has its length, data checksum, and 
originating address recorded in a table, along with 


a timer. If matching packets arrive, usually by 
different relay routes, only the first one will be 
repeated until the timer expires. That way we cut 
down on the clutter on the channel, since some- 
thing addressed through several RELAY's and 
WIDE's will echo several times and may loop back 
through. Second, we use callsign replacement to 
replace any generic alias (RELAY or WIDE) with 
our own node's callsign, and even if the timer has 
expired or the table got full, we don't repeat a 
packet again that it can see it has already repeated. 
Third, we have implemented the WIDE-n scheme, 
where we decrement the ssid of WIDE if it is in the 
range of -1 to -7, which is a scheme to propagate 
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packets radially outwards through a digipeater net- 
work. The SSID is decremented, instead of setting 
the "used" bit so it can be used again by the next 
digipeater. (Note also that TexNet as a whole only 
recognizes any packets having no more than 4 
digipeater "via" addresses, it ignores packets with 
more). Fourth, while the datagram is in transit over 
the network, it is flying "space available" with other 
network traffic which is normally presumed to be 
connected-mode traffic. All of the trunk traffic is of 
course flying on a connected mode trunk, but the 
network knows which ones are APRS packets, and 
they will be discarded should that datagram en- 
counter network congestion. The definition of net- 
work congestion is encountering a trunk circuit with 
30 or more packets queued up waiting to be trans- 
mitted to the next node. Unless we have a trunk 
propagation problem, or someone initiates a big 
connected mode file transfer, or unless a real flurry 
of APRS packets come along, this condition 
shouldn't happen. If it did, it would also be likely 
that the packets would grow too "old" before they 
arrived. Since the basic nature of APRS is to use 
unguaranteed UI delivery and compensate by re- 
dundant refreshes over time, this behavior 
shouldn't normally be a problem. Fifth, when the 
APRS datagram arrives at its intended destination, 
it is transmitted on the node's designated APRS 
port, normally the one with the radio on 144.39. It 
should be noted that any node port will accept 
APRS packets, even the trunk itself. In fact, if it 
were absolutely necessary to support an emer- 
gency such as an aerial search or firewatch, it 
would be acceptable and probably most effective to 
put the tracker on the trunk frequency, normally a 
9600b UHF radio, at least in the first few years until 
most of the nodes that can do so have had the 
extra 144.39 mods done. Indeed, this situation 
almost happened this summer to support a re- 
gional CAP and forestry dept aerial firewatch, and 
the incident provided most of the useful input to the 
design of this scheme. That aerial survey was 
reported on the SIG earlier this summer. 


Where are we headed next? | think it may be 
possible over the next year or so to establish 
coverage on the majority of I-35 across Texas. We 
have tentative plans to install radios on 144.39 in 

(Continued on page 12) 


Page 11 


(Continued from page 11) 

downtown San Antonio and in downtown Dallas on 
reasonably high multistory sites that we already 
have in operation. Plans are underway, things 
aren't finalized, and for these two sites we would 
like to see the local APRS users pool their re- 
sources and contribute radios, and for the San 
Antonio site also an antenna. A node has been 
constructed, awaiting antenna installation on a tall 
broadcast tower in Austin, and this node will have 
an APRS port on 144.39 which ought to have some 
good range, and also will be fitted with a DGPS 
reference station. | may install another APRS port 
on the DXC node in Round Rock, north of Austin. 
There is some interest in Denton and Sherman, 
north of Dallas/Ft Worth. | have been tinkering with 
the idea of at least one, if not several HF receivers 
on 10.15, but that is just a concept at this time. 
Last, some internet trunk connectivity is being 
designed into TexNet in an effort to expand our 
network coverage to places we can't get to with 
either RF or some of our donated commercial 
wirelines, and when some of that is in place, it is 
possible that we may establish a permanent bridge 
to the various internet APRS servers that now exist. 


That is also just a concept now. Also, | intend to 
install a combination TexNet server node and 
APRS system in the Austin/San Antonio NWS 
office, and when that is successful | would like to 
see it duplicated other places in the region. That 
system is currently under construction, although 
the design seems to change faster than construc- 


tion proceeds. In our particular situation, 
floorspace/tablespace inside that NWS office is a 
major limitation and has slowed things down there 
due to a crowded office while NWS installs up- 
graded equipment of their own. | may just have to 
wait it out. 


For those elsewhere not familiar with TexNet, it is a 
Z80 based packet network node, running on either 
TPRS custom 3-port hardware, or on single or 
dual-ported (modified) TNC2's. It employs 9600b 
UHF radio network trunking, to provide 1200b 
packet user service over quite a bit of Texas, and 
parts of Oklahoma, Arkansas, and a little bit of 
Missouri. Louisiana is expected to join soon. 
TPRS writes, owns,and maintains its own network 
code, so it is an actual amateur supported project 
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of both hardware and software. That is one reason 
we can add APRS to the code if we choose to. This 
network is in a state of flux, rathar than one of 
decline, we add nodes as well as ocassionally lose 
or relocate them. We expect to use some internet 
trunking support to expand the network, rathar than 
see it decline as has happened elsewhere. Most of 
our support comes from DXC's and BBS forward- 
ing, and | believe that APRS can become an 
additional base of support for the network. Packet 
traffic is down as a whole from what it has been in 
the past, and our system often has quite a bit of 
available bandwidth. TexNet also since its incep- 
tion in the mid 1980's grew up in and around 
Tornado Alley, and always has had considerable 
support functionality for skywarn uses and emer- 
gency operations in general, and APRS will cer- 
tainly add much to that. 


There is also some TexNet networking in the Michi- 
gan/Indiana area, known there as GL-NET. Occa- 
sionally we compare notes with those folks, and if 
they are interested in retrofitting the system, which 
is primarily replacing the eproms and maybe 
adding modems and radios, let me know. Any 
future expansion of TexNet will have to be done 
with the TNC2 dualported platform, or the TAPR- 
TNC3 ifAwhen it ever goes into production. The 
later future of TexNet hardware will lie with porting 
the layer-3 network code to Linux, which will start to 
happen over time, and | expect it to also dovetail 
into the TAPR Spread Spectrum efforts as they 
ripen and become available for radio networking. 


Editor’s Note 


Sorry for the lousy quality of the pictures last time. 
They looked ok on my inkjet printer but, when 
printed on the laser printer, were too dark. 


Your articles are welcome! Please email them in 
some known format (Word 6 or 97 preferred) to 
brads@galstar.com. 


Thanks! 
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TPRS Node Assigments 
Official Publication: June, 1995 
Subject to Corrections/Additions/Deletions. 


= ACTIVE/COMPLETED 
ACTIVE/TEST 
= PENDING 


User 
Nr Status City/Town Alias Call Port Remarks 
Dallas TEXNET WR5C 145.05 PMS 
Richardson TESTBED W9DDD None R&D 
Richardson RICH W9DDD None R&D 
Murphy MURPHY NSEG 145.09 
Ft. Worth NWS N5HCO None Weather PMS 


Beorne BEORNE N5VUO 145.01 (Bridged w/BN 
Geronimo GERONMO WB5SNSN_ 145.07 PMS (AKA GER 
Austin AUSTIN WASLHS 145.07 

Austin NQ90 Bryan Stroud Test Node 

San Antonio ALAMO NOCCW 145.09/223.44 

San Antonio SALAMO WA2MCT Interface to SNS/NO USER PORT 
Denton DENTON W5SNGU 145.03 

Lubbock LUBBOCK W5ERO 145.05 

Midland MIDLAND WB5SRXA 145.05 

Greenville GREENVL WB5IZL 145.07 

Midland MAFDXC WF5E 223.58 DXCluster port 2 


OAAITAUHAWNE 


1x KKM KKM XM HX XO 


Rockport ROCPRT N5JKH 144.99/PORT 2 446.1 
C. Christi CORPUS N5XCH 145.05 INTERFACE TO SNS 
Pettus PETTUS KA5SBWL 147.56 

Corpus ESTES KB5GD None Test Node 
Lubbock LBBDXC KA5EJX DXCLUSTER 

Austin AUSDXC WB5VZL 144.99 

Corpus Ch CCSU N5SAHD TEXT Node 

Victoria VCTRIA W5DSC 145.01 

Alice ALICE K5DYY 145.07 

Amarillo AMARILO WD5ILA 145.05 

Abilene ABILENE WBSEKW 145.05 


5 
5 
5 
3 
Austin NQ90 Bryan Stroud Test Node 
4. 
5: 
Te< 


ix x xX 


xxx x UK XM 


Houston HOUSTON WD5HJP UNKN Due 
Pearland PEARL UNKN UNKN Due 
Rosenburg ROSBRG UNKN UNKN Due 
San Antonio SANTEX WB5SFNZ 223.58 

Hempstead HMPSTD Due 


tax tO tO tD 


Kingsville TAMUK W5ZD 144.91 (aka KINGVL) 
Bryan/CollStn SBRAZOS KF5LN 145.05/446.10 Port 0 (PENDING 
RE-INSTALLATION) 
Bryan/CollStn NBRAZOS KG5ZD 446.1 (See Nr 43) 

Fannin County FANNIN WB5RDD 145.05 

Sherman SHERMAN WBSCVR 144.93 

South Dallas SDALLAS KF5RN 
Waco WACO WD5KAL 145.09 
Falfurrias FALFUR WB5FRO None 


ux 
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Mercedes VALLEY NASC 144.60 DxXCluster port 2 

San Isidro ISIDRO K5RAV None 

Brownsville BROWX K5RAV-? NWS node 25.54.57N 97.25.08W 
Fort Worth FTWORTH N5AUX 144.99 

AOHTST AUSTIN WB5AOH NONE R&D AUSTIN 

Murphy CARDNAL WA6ROC None R&D/PMS/NMS/NETCON 


xHSx UX 


(100-150) Reserved for TexLink Node Usage 
Floresville LORES WD5DOE None 


King Mountain I WB5YHC 145.05 
Alpine I WASROE 145.05 
Refugio WB5OLT None 

San Angelo I WASJSN 145.05 


PLAINVIEW ] KCS5ALN 145.05 


Reserved -— WB5DDP 
Reserved -— WB5DDP 


Moody MOODY W5ZDN 


(151-249) Reserved for Non-Texas Node Usage 


Ft Gibson OK FTGIBSN N5GIT 145.01 
Muskogee OK MKOTST WASVMS 446.5 PMS 
Muskogee OK MUSKOGE W5EJK 145.09 


Lincoln AR FAYETVL K5VR 14 
Clayton OK CLAYTON W5CUQ 145. 
Ft Smith AR FTSMITH W5ANR 144. 


Tulsa OK TULWX NSWX NWS Server 
Okemah OK OKEMAH WBSHLR 
Choctaw OK CHOCTAW AB5H 


Garfield AR GARFLD WB2ROC 
Aurora Missouri OARSMO KOSQS 
Mt Magazine AR MAGAZIN KF5XB 
Russellville RSLVL WB5BHS 
Little Rock AR LROCK WB5SQK 144.97 PORT 2 446.50(FUTUR 
Little Rock AR LRTS KA5SQK TEST Node 


(250-255) Network Reserve 


If you are a TexNet node opearator/owner and have a correction to 
make to the list, advise to 

NOCCW@K3WGF.#STX.TX.USA.NOAM, or leave a message for 

NOCCW on the NDALLAS PMS of TexNet. 
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TPRS Membership Application 


Name Callsign 
Address 

Apt. or Mailstop 

City/State 

Zip E-mail address 


Evening Phone (_) Work Phone (__) 


Membership is $12 per year. How many years are you paying for? 


New Member Renewal 


Make check payable to: Texas Packet Radio Society 


—-—----------Y 


ATIN: 


Membership Texas Packet Radio Society 


P.O. Box 50238 
Denton, Texas 76206-0238 


Texas Packet Radio Society, Inc. 


Be sure to visit the TPRS web page: 


TP RS 1 998 http://www.tprs.org 


for the latest information on TPRS 


Fall Digital activities. 


Sym posium A current listing of Packet nodes, 
frequencies, and networks is located in the 
Dec 1 2, 1 998 North American Digital Systems 
Austin, TX. Directory (NADSD) on-line at: 
http://www.tapr.org/directory/index.html 


OO A A AO A A A A A A A A A A A A A A A ae 


Texas Packet Radio Society 
P.O. Box 50238 
Denton, Texas 76206-0238 


ADDRESS CORRECTION REQUESTED 


To: 


